The present invention relates to methods and apparatus for processing data within a computer network. More specifically, it relates to mechanisms for handling SCTP (Stream Control Transmission Protocol) Multi-homed connections, especially across multiple NAT (network address translation) or PAT (port address translation) devices.
SCTP is a reliable transport protocol which along with TCP (Transmission Control Protocol), UDP (User Datagram Protocol), and RTP (Real-Time Transport Protocol) provides transport layer services for upper layer protocols and services. One of the important capabilities of SCTP, and which is not provided by TCP, is Multi-Homing. SCTP provides transparent support for communications between two endpoints of which one or both is multi-homed, wherein an endpoint has a primary address and one or more alternative addresses through which it may be accessed by other endpoints. SCTP provides monitoring of the reachability of the addresses on the remote endpoint and in the case of failure can transparently failover from the primary address to an alternate address, without upper layer intervention.
This capability can be used to build redundant paths between two SCTP endpoints and can be particularly useful for applications that seek transport-level fault tolerance. Achieving path redundancy between two SCTP endpoints normally requires that the two endpoints are equipped with multiple interfaces assigned with multiple addresses and that routing is configured appropriately.
Path failure detection mechanisms for SCTP are described in detail in Section 8.2 of RFC 2960, entitled “Stream Control Transmission Protocol”, Network Working Group of Internet Engineering Task Force (IETF), October 2000, which document is herein incorporated by reference in its entirety. This RFC document states that an SCTP endpoint shall monitor the reachability of the idle destination transport address(es) of its peer by sending a HEARTBEAT chunk periodically to the destination transport address(es). If there are no corresponding HEARTBEAT-ACK chunks received and if the number of retransmission attempts of HEARBEAT chunks exceeds a certain threshold, the endpoint then should mark the destination transport address as inactive. When the primary path is marked inactive (due to excessive retransmissions, for instance), the sender may automatically transmit new packets to an alternate destination address if one exists and is active. If more than one alternate address is active when the primary path is marked inactive only one transport address should be chosen and used as the new destination transport address.
The SCTP Applicability Statement describes a multi-homed scenario where one end-point 102 is behind a single NAT device 104 as shown in FIG. 1. For example, another endpoint 108 may communicate with endpoint 102 via Internet 106 and NAT device 104.
For a particular computer to communicate with other computers or web servers within a network (e.g., the Internet), the particular computer must have a unique IP address. IP protocol version 4 specifies 32 bits for the IP address, which theoretically gives about 4,294,967,296 unique IP addresses. However, there are actually only between 3.2 and 3.3 billion available IP addresses since the addresses are separated into classes and set aside for multicasting, testing and other special uses. With the explosion of the Internet, the number of IP addresses is not enough to give each computer a unique IP address.
One solution for addressing computers with the limited number of IP addresses is referred to as network address translation (NAT). NAT allows an intermediary device (e.g., computer, router or switch) located between the Internet network and a local network to serve as an agent for a group of local computers. A small range of IP addresses or a single IP address is assigned to represent the group of local computers. Each computer within the local group is also given a local IP address that is only used within that local group. However, the group's local IP addresses may duplicate IP address that are used outside of the local network. When a local computer attempts to communicate with a computer outside the local network, the intermediary device matches the local computer's local IP address (and port) to one of the intermediary device's assigned IP addresses (and ports). The intermediary device then replaces the local computer's local address (and port) with the matched assigned IP address (and port). This matched assigned IP address (and port) is then used to communicate between the local computer and the outside computer. Thus, NAT techniques allow IP address to be duplicated across local networks.
The above referenced Applicability Statement describes how to handle messages sent through a single NAT device, as shown in FIG. 1, and such description is further described in RFC 3257, entitled “Stream Control Transmission Protocol Applicability Statement”, Network Working Group of Internet Engineering Task Force (IETF), April 2002, which document is herein incorporated by reference in its entirety. RFC3257 proposes the following to deal with the above scenario:                “The NAT must have a public IP address for each represented internal IP address. The host can preconfigure an IP address that the NAT can substitute, or, the NAT can have internal Application Layer Gateway (ALG) which will intelligently translate the IP addresses in the INIT and INIT ACK chunks.” For the Overload (PAT) case: “If Network Address Port Translation is used with a multihomed SCTP endpoint, then any port translation must be applied on a per-association basis such that an SCTP endpoint continues to receive the same port number for all messages within a given association.”The assumption in the above scenario is that IP Routing is set up in such a way that packets destined to the primary and “secondary” address of the multi-homed endpoint traverse the same NAT.        
But more often in a multi-homed scenario, the above is not true. Packets destined to the “secondary” address may be traversing an entirely different path where there may be a different NAT device along that path. This scenario is illustrated in FIG. 2, wherein a first Host A 202 may be reached along two different paths. A first path passes through a first NAT1 device 204, while a second path passes through a second different NAT2 device 206. Thus, another host, such as Host B (210), may communicate with Host A (202) through, for example, the path through NAT1 device 204 or the path through NAT2 device 206 via the Internet 208, for example.
SCTP association will fail in the above scenario, when Host B (210) sends packets to the secondary address of Host A (202) through NAT2 (206), rather than NAT1 (204). NAT2 device does not have the intelligence to allow the packets destined to Host A's (202) secondary address.
In view of the above, there is a need for improved mechanisms for reliably handling SCTP multi-homed connections across multiple NAT devices.